On AArch64, the autoload INIT_WRAPPER passes its func_info* argument in
x30 (mov x0, x30), which is only valid when the wrapper is reached via
the trampoline'\''s blr to the FIRST init function (std_dll_init). A second,
chained INIT_WRAPPER'\''d init -- wsock_init, used only by ws2_32 -- is
reached from dll_chain via a tail "br x1", which does not set x30. So
wsock_init received a garbage func_info, read dll->handle as 0, and
GetProcAddress((HMODULE)0, "WSAStartup") returned NULL: WSAStartup was
never called and Winsock was never initialized. Every ws2_32 function
(GetAddrInfoW, socket, gethostbyname) then ran against uninitialized
Winsock -> EFAULT / hang / WSANOTINITIALISED (10093).

This affected only ws2_32 (the sole DLL with a secondary INIT_WRAPPER
init); all other DLLs chain straight to dll_func_load, which reads
func_info from the stack and is unaffected. x86_64 was unaffected
because its INIT_WRAPPER reads the argument from the stack in both
positions.

Fix: have dll_chain also place func_info in x30 before the tail-branch,
so a chained INIT_WRAPPER init gets the correct argument. dll_func_load
is unaffected (it reads func_info from [sp]); std_dll_init is unaffected
(reached via blr, not dll_chain).

… dll_chain frame)

Second half of the AArch64 ws2_32 chained-init fix. After the x30 fix let
wsock_init run WSAStartup, the FIRST ws2_32 call in a process still faulted
(later fast-path calls worked). Cause: ws2_32 is the only DLL with a chained
second init stage, so dll_chain runs twice (-> wsock_init, -> dll_func_load),
each pushing a 16-byte func_info frame. wsock_init takes its arg from x30, not
the stack, so the frame dll_chain pushed before wsock_init is never consumed
and strands on the stack. dll_func_load assumes exactly one dll_chain frame
above the trampoline register-save frame, so it then restores the caller arg
registers from a 16-byte-shifted offset, corrupting the first real call.

Fix: give aarch64 wsock_init a dedicated INIT_WRAPPER that drops the stranded
dll_chain frame (extra add sp,#16) before chaining to dll_func_load. x86_64
keeps the shared INIT_WRAPPER (its dll_chain push/0x28(%rsp) mechanism is not
affected). std_dll_init keeps the plain wrapper (reached via blr; no stranded
frame).